- tambah gateway
- ubah service task type
- tambah variable
- tambah timer
- tambah worker
- ubah retry count
- tambah user task
- deploy BPMN versi baru

running process instance behavior changes
worker starts producing duplicate side effect
message correlation stops matching
user task becomes invisible
incident volume increases
SLA timer starts firing too aggressively
process state diverges from quote/order state
migration becomes impossible
customer-impacting order flow gets stuck

Model change
Deployment
New process instance start
Existing process instance behavior
Worker activation
External side effect
Variable update
Message/timer/error handling
Human task handling
Retry/incident path
Observation/debugging
Rollback/forward recovery

BPMN service task type != worker job type
BPMN variable name != worker variable name
Message correlation key != API/Kafka event key
User task candidate group != application authorization group
Retry policy != idempotency guarantee
Process version != worker version
Timer policy != SLA expectation

BPMN
DMN
Forms
Java/JAX-RS endpoint
Worker implementation
PostgreSQL/MyBatis mapper
Kafka topic/event schema
RabbitMQ queue/routing key
Redis cache/lock/idempotency key
Kubernetes deployment
Helm/GitOps manifest
Dashboard/alert
Runbook

Can every process instance finish or reach a known manual state?
Can every failure be retried, compensated, escalated, or repaired?
Can every side effect be deduplicated?
Can every human task be found and completed by the right actor?
Can every message be correlated deterministically?
Can every production incident be debugged with available evidence?

[ ] Menambah/mengubah BPMN gateway.
[ ] Menambah/mengubah service task.
[ ] Menambah/mengubah user task.
[ ] Menambah/mengubah message/timer/error/escalation/compensation event.
[ ] Mengubah variable contract.
[ ] Mengubah business key/correlation key.
[ ] Mengubah retry count/backoff/timeout.
[ ] Mengubah worker job type/topic.
[ ] Mengubah worker concurrency atau deployment replica.
[ ] Mengubah state transition quote/order.
[ ] Mengubah integration ke external API/Kafka/RabbitMQ/Redis.
[ ] Mengubah BPMN/DMN deployment pipeline.
[ ] Mengubah process versioning/migration policy.
[ ] Mengubah authorization/task visibility.
[ ] Mengubah incident handling or manual repair path.

What business process is being modeled?
What entity/entities does it orchestrate?
What is the start condition?
What is the success end condition?
What are known non-success end states?
What manual intervention states exist?
What external systems are involved?

[ ] Start event jelas: API, message, timer, manual, or internal call activity?
[ ] Start event punya business key/correlation key strategy?
[ ] Multiple start events tidak menciptakan ambiguity?
[ ] End events mencerminkan business outcome, bukan hanya technical completion?
[ ] Terminate end event digunakan dengan sadar?
[ ] Non-happy-path end state punya audit reason?

[ ] Semua branch gateway punya condition jelas.
[ ] Exclusive gateway punya default flow jika data bisa tidak lengkap.
[ ] Parallel split punya join yang benar atau sengaja fire-and-forget.
[ ] Inclusive gateway tidak menciptakan join yang sulit diprediksi.
[ ] Event-based gateway tidak menyebabkan race yang tidak ditangani.
[ ] Tidak ada dead path.
[ ] Tidak ada path tanpa end state.
[ ] Tidak ada loop tanpa exit condition.

user task
receive task
message catch event
timer event
external task / Zeebe job
async continuation
call activity

[ ] Wait state punya owner.
[ ] Wait state punya timeout/SLA jika business perlu.
[ ] Wait state observable di Cockpit/Operate/dashboard.
[ ] Wait state punya manual repair path.
[ ] Wait state punya correlation key jika menunggu external message.

[ ] Diagram tidak menjadi god process.
[ ] Diagram tidak mengganti domain service/business logic.
[ ] Gateway tidak menyembunyikan rules besar.
[ ] Service task tidak diberi nama technical-only seperti "call api" tanpa business intent.
[ ] Variable tidak terlalu banyak.
[ ] Tidak ada large payload di process variable.
[ ] Tidak ada sync blocking call panjang tanpa timeout.
[ ] Tidak ada human task tanpa SLA/assignment.

[ ] Decision punya business owner.
[ ] Input/output jelas dan versionable.
[ ] Hit policy benar.
[ ] Rule order penting atau tidak?
[ ] Default/no-match behavior jelas.
[ ] Ambiguous match ditangani.
[ ] Decision table punya test cases.
[ ] Decision change punya audit trail.
[ ] Decision tidak membaca variable rahasia yang tidak perlu.
[ ] DMN tidak menggantikan rules engine jika rules sangat kompleks/dynamic.

pricing approval threshold
enterprise discount approval
eligibility decision
manual review routing
fallout classification
renewal/cancellation rule

[ ] User task mewakili keputusan/aksi manusia yang valid secara bisnis.
[ ] Task name jelas bagi user operasional.
[ ] Task description/form menjelaskan konteks keputusan.
[ ] Candidate group/user jelas.
[ ] Assignment rule bisa diuji.
[ ] Due date/follow-up date/SLA jelas.
[ ] Task completion outcome eksplisit.

[ ] Assignment tidak dianggap sama dengan authorization.
[ ] Backend/JAX-RS tetap enforce authorization.
[ ] Task query difilter tenant/customer/role.
[ ] User tidak bisa complete task milik tenant lain.
[ ] Operator tidak bisa melihat variable sensitif tanpa izin.
[ ] Audit mencatat siapa claim/complete/reassign.

[ ] Concurrent completion ditangani.
[ ] Stale UI mendapat response yang benar.
[ ] Save draft tidak sama dengan complete.
[ ] Form validation dilakukan server-side.
[ ] Task sudah completed/cancelled tidak bisa disubmit ulang.

[ ] Aging task dashboard tersedia.
[ ] SLA breach alert tersedia.
[ ] Escalation owner jelas.
[ ] Manual override butuh privilege dan audit.
[ ] Tasklist outage impact dipahami.

JavaDelegate class
External task topic
Expression/bean resolution
Async before/after
Retry cycle
BPMN error behavior

job type
worker name
max jobs active
job timeout
retries
backoff
input/output mapping
BPMN error behavior

[ ] BPMN service task type/topic cocok dengan worker implementation.
[ ] Worker membaca variable minimal yang diperlukan.
[ ] Worker menulis variable minimal yang diperlukan.
[ ] Worker punya deterministic idempotency key.
[ ] Worker tidak melakukan side effect sebelum validation cukup.
[ ] Worker timeout realistis.
[ ] Worker failure melaporkan reason yang dapat di-debug.
[ ] BPMN error hanya untuk business error yang bisa ditangani process.
[ ] Technical error menjadi retry/incident, bukan branch bisnis palsu.

update PostgreSQL business table
call external API
publish Kafka event
publish RabbitMQ message
write Redis key
send notification
create downstream order/provisioning request

[ ] Side effect idempotent.
[ ] Duplicate execution aman.
[ ] Unknown outcome bisa direkonsiliasi.
[ ] External API idempotency key digunakan jika tersedia.
[ ] DB write dilindungi unique constraint/version check.
[ ] Event publish memakai outbox jika perlu atomicity dengan DB.
[ ] Worker complete hanya setelah side effect berada di durable state.

[ ] Replica count sesuai throughput dan downstream capacity.
[ ] Concurrency tidak melebihi DB/API limit.
[ ] Graceful shutdown menangani active job.
[ ] Liveness/readiness tidak membunuh worker yang sedang drain.
[ ] Rolling deployment tidak menciptakan version mismatch.
[ ] Metrics per worker/job type tersedia.

[ ] Variable name stabil dan konsisten.
[ ] Variable type jelas.
[ ] Variable scope benar: global vs local.
[ ] Input/output mapping tidak overwrite variable paralel.
[ ] Sensitive data tidak disimpan jika tidak perlu.
[ ] Large payload tidak masuk process variable.
[ ] Variable schema/versioning dipikirkan.
[ ] Running process instance lama tetap compatible.
[ ] Worker lama/baru bisa membaca variable sesuai rollout plan.
[ ] Variable auditability dan retention sesuai requirement.

process variable berisi full quote/order payload besar
worker menulis ulang seluruh object variable
parallel branches update object yang sama
variable digunakan sebagai source of truth utama
secret/API token tersimpan di variable

[ ] Message name stabil dan versioning strategy jelas.
[ ] Correlation key deterministic.
[ ] Correlation key tidak berubah selama lifecycle.
[ ] Business key dan correlation key tidak tertukar.
[ ] Duplicate message aman.
[ ] Late message policy jelas.
[ ] Missing message bisa dideteksi.
[ ] Message TTL/expiration sesuai business process.
[ ] Kafka/RabbitMQ/API callback metadata cukup untuk debugging.
[ ] Signal tidak digunakan ketika target harus spesifik satu process instance.

What happens if callback arrives before process reaches catch event?
What happens if callback arrives twice?
What happens if Kafka replay sends old event?
What happens if RabbitMQ redelivers reply after timeout?
What happens if tenant/correlation key mismatch?

[ ] Timer type jelas: date, duration, or cycle.
[ ] Timezone assumption jelas.
[ ] Business calendar limitation dipahami.
[ ] Timer is used for SLA/timeout, not hidden polling hack.
[ ] Timer backlog observable.
[ ] Timer migration impact dipahami.

[ ] Retry count sesuai failure mode.
[ ] Backoff tidak menciptakan retry storm.
[ ] Worker idempotent sebelum retry diaktifkan.
[ ] Non-retryable business error tidak diretry terus.
[ ] Poison task akan menjadi incident/manual intervention.
[ ] Retry reason/log cukup untuk triage.

[ ] Incident owner jelas.
[ ] Incident dashboard tersedia.
[ ] Incident punya severity/customer impact mapping.
[ ] Resolve incident tidak hanya menekan tombol retry tanpa root cause.
[ ] Manual repair path terdokumentasi.

[ ] Semua step yang punya irreversible side effect diidentifikasi.
[ ] Compensation action tersedia jika business memungkinkan.
[ ] Compensation tidak diasumsikan selalu mengembalikan state 100%.
[ ] Partial failure state eksplisit.
[ ] Manual recovery state eksplisit.
[ ] Reconciliation tersedia untuk external system mismatch.
[ ] Compensation idempotent.
[ ] Compensation failure punya incident path.

cancel downstream order
release reservation
void approval
send correction request
mark fallout
open manual repair task
create reconciliation ticket

[ ] Endpoint yang start workflow memakai 202 Accepted jika proses long-running.
[ ] Response tidak menjanjikan completion sinkron jika tidak benar.
[ ] Idempotency key tersedia untuk start/command endpoint.
[ ] Correlation ID masuk log, worker, event, and process variable minimal.
[ ] Authorization diperiksa sebelum start/complete/correlate.
[ ] API error mapping membedakan validation, conflict, not found, unauthorized, and workflow unavailable.
[ ] Status endpoint tidak membocorkan variable sensitif.
[ ] Polling/callback contract jelas.
[ ] Duplicate request tidak memulai process ganda.

POST /orders returns 200 OK "completed" padahal fulfillment masih berjalan
POST /tasks/{id}/complete tidak cek assignee/tenant
POST /callbacks/status hanya correlate berdasarkan orderId tanpa tenant/domain guard
GET /process/{id} mengembalikan semua variables mentah

[ ] Business table tetap source of truth untuk domain state.
[ ] Process variable tidak menggantikan business table.
[ ] Worker DB transaction jelas.
[ ] Commit-before-complete pattern digunakan dengan sadar.
[ ] Processed job/inbox table punya unique constraint.
[ ] Outbox digunakan jika DB update + event publish harus durable.
[ ] Optimistic locking menangani concurrent state transition.
[ ] MyBatis mapper tidak melakukan broad update tanpa state guard.
[ ] Migration DB compatible dengan running workflow.
[ ] Reconciliation query tersedia.

What if DB commit succeeds but worker complete fails?
What if worker complete succeeds but event publish fails?
What if workflow retries after partial DB update?
What if schema migration removes field used by running process version?

[ ] Event key/correlation key jelas.
[ ] Event schema versioning aman.
[ ] Duplicate event idempotent.
[ ] Out-of-order event policy jelas.
[ ] Replay impact dipahami.
[ ] Consumer offset failure tidak menggandakan side effect tanpa protection.
[ ] Event metadata cukup: tenant, correlation ID, causation ID, process/business ID.

[ ] Exchange/queue/routing key jelas.
[ ] Ack/nack/requeue policy jelas.
[ ] DLQ policy jelas.
[ ] Retry layer tidak tumpang tindih dengan Camunda retry secara berbahaya.
[ ] Reply correlation aman.
[ ] Duplicate delivery idempotent.

[ ] Redis tidak menjadi source of truth process/business state.
[ ] Lock punya TTL dan fencing/ownership awareness.
[ ] Idempotency cache punya durable fallback jika dibutuhkan.
[ ] Rate limiter failure mode jelas.
[ ] Cache staleness tidak membuat task/action salah.
[ ] Redis outage impact diketahui.

[ ] Process start/action access controlled.
[ ] Task query/complete access controlled.
[ ] Variable access restricted.
[ ] Tenant isolation applied end-to-end.
[ ] Sensitive variable minimized/redacted.
[ ] Incident/log payload tidak membocorkan PII/secret.
[ ] Connector secret tidak masuk BPMN/plain env dump.
[ ] Worker credential least privilege.
[ ] mTLS/OAuth/OIDC/service account model jelas.
[ ] Audit log cukup untuk compliance evidence.
[ ] Retention/history cleanup sesuai requirement.

[ ] Metrics per process definition/version tersedia.
[ ] Metrics per job type/topic tersedia.
[ ] Worker latency, throughput, failure rate tersedia.
[ ] Incident count and aging tersedia.
[ ] Task aging/SLA breach tersedia.
[ ] Message correlation failure tersedia.
[ ] Timer backlog tersedia.
[ ] Variable/payload size monitored jika berisiko.
[ ] Correlation ID konsisten API -> worker -> DB -> message -> log.
[ ] Dashboard/runbook link ditambahkan ke PR/release notes.

active process instances
completed process instances
failed jobs/incidents
oldest active user task
oldest active incident
job activation latency
worker error rate
message correlation failures
timer backlog
external API failure rate
DB slow query / lock wait

[ ] Expected process volume diketahui.
[ ] Expected job volume per process diketahui.
[ ] Worker concurrency sesuai downstream capacity.
[ ] Retry volume termasuk dalam capacity plan.
[ ] Timer burst dipertimbangkan.
[ ] Payload/variable size dikontrol.
[ ] Camunda 7 DB pressure dipertimbangkan.
[ ] Camunda 8 partition/broker/search dependency dipertimbangkan.
[ ] Load test mencakup failure path, bukan hanya happy path.
[ ] Backpressure behavior dipahami.

increase worker replicas without downstream limit analysis
large object variables on every step
retry every 1 second on external outage
parallel gateway fans out to many API calls without rate limit
no history cleanup/retention plan

[ ] BPMN/DMN/form deployed via controlled pipeline.
[ ] Process versioning strategy jelas.
[ ] Running instance impact dianalisis.
[ ] Worker backward/forward compatibility jelas.
[ ] Variable compatibility jelas.
[ ] Message correlation compatibility jelas.
[ ] Rollback strategy realistis.
[ ] Forward recovery plan tersedia.
[ ] Migration plan tersedia jika running instance harus dipindahkan.
[ ] Bad deployment runbook tersedia.

Should this be workflow, state machine, queue, scheduler, or rules engine?
Should this use Camunda 7 or Camunda 8?
Should automation be JavaDelegate, external task, Zeebe worker, or connector?
Should this be BPMN branch or DMN decision?
Should this be orchestration or choreography?
Should running process instances be migrated or drained?
Should process state or entity state be source of truth?
Should this process be split into call activity/subprocess?
Should this task be human/manual or automated?

# ADR: <decision title>

## Context
What business/process problem exists?

## Decision
What are we choosing?

## Alternatives
What did we reject?

## Consequences
Runtime, data, security, ops, migration, and support impact.

## Failure Model
How can this fail and how do we detect/repair it?

## Rollout Plan
How will this reach production safely?

## Internal Verification
What must be checked in CSG repositories/environments/teams?

What is the business invariant being protected?
What is the source of truth for state?
What happens if this worker executes twice?
What happens if this message arrives late?
What happens if this timer fires during outage recovery?
What happens if this process is already running on old version?
What happens if deployment succeeds but worker rollout fails?
What happens if external API succeeds but worker crashes before completion?
What happens if user completes stale task?
What happens if tenant/correlation key is wrong?
How would SRE know this is failing?
How would support safely repair this?
What evidence would we show in an audit?

## Workflow Review

### Business intent
- [ ] Process/business outcome jelas
- [ ] Happy path and non-happy path jelas
- [ ] Business owner/operational owner jelas

### BPMN/DMN correctness
- [ ] Gateway/event/task semantics benar
- [ ] DMN/rule boundary benar
- [ ] Wait state and timeout clear

### Worker/integration
- [ ] Job type/topic matches implementation
- [ ] Idempotency guaranteed
- [ ] Retry/failure behavior safe
- [ ] DB/API/event side effects safe

### Data contract
- [ ] Variable names/types/scopes reviewed
- [ ] Sensitive/large payload avoided
- [ ] Backward compatibility reviewed

### Human task
- [ ] Assignment and authorization reviewed
- [ ] SLA/aging/escalation reviewed
- [ ] Stale/concurrent completion handled

### Operations
- [ ] Metrics/logs/traces/alerts updated
- [ ] Incident/manual repair path clear
- [ ] Deployment/versioning/migration impact reviewed
- [ ] Runbook updated if needed

### Security/compliance
- [ ] Tenant/access/variable privacy reviewed
- [ ] Audit evidence sufficient

[ ] Di repository mana BPMN/DMN/form disimpan?
[ ] Apakah PR workflow direview oleh backend + BA/product + platform/SRE?
[ ] Apakah ada template PR khusus BPMN/worker?
[ ] Apakah ada ADR untuk keputusan workflow besar?
[ ] Apakah Camunda 7, Camunda 8, atau custom engine dipakai?
[ ] Apakah worker job type/topic naming convention terdokumentasi?
[ ] Apakah process variable naming convention terdokumentasi?
[ ] Apakah retry/incident policy per task terdokumentasi?
[ ] Apakah manual repair action butuh approval?
[ ] Apakah Operate/Cockpit/dashboard menjadi bagian review?
[ ] Apakah process versioning dan migration strategy ada?
[ ] Apakah task assignment/authorization dicek dengan security team?
[ ] Apakah Kafka/RabbitMQ/Redis integration punya review checklist sendiri?
[ ] Apakah production incident sebelumnya pernah disebabkan workflow?
[ ] Apakah postmortem notes mengubah checklist review?

Can it start safely?
Can it finish safely?
Can it fail safely?
Can it retry safely?
Can it be observed safely?
Can it be repaired safely?
Can it evolve safely?
Can it protect customer/tenant/sensitive data?

Does this BPMN look correct?

Will this process remain correct when workers crash, messages duplicate, timers fire late, users act concurrently, process versions change, infrastructure fails, and operators need to repair it under pressure?