Db Design

Workflow

1. Start from actors, business process, use cases, lifecycle, and reporting needs instead of jumping to tables.
2. Separate functional rules from non-functional constraints such as scale, concurrency, and operational limits.
3. Define the conceptual domain model first: entities, relationships, cardinality, ownership, and business meaning.
4. Map read/write paths, filters, alternate flows, and expected scale to propose indexes and denormalization only where justified.
5. Plan migration sequencing, backfill needs, rollback safety, and contract compatibility.
6. Return the model and the operational implications.

Output

• Conceptual domain-model notes and logical model notes.
• Physical-model implications when storage or migration shape matters.
• Table, key, index, and migration recommendations.
• Risks around integrity, performance, and rollback.

Validation

• Smoke-test with a schema-from-use-case request and confirm entities, relationships, access patterns, indexes, and migration sequencing are explicit.
• Smoke-test with a migration review and confirm rollback, integrity, and performance risks are called out.

References

• Read docs/knowledge-base/README.md for requirements, BPMN, and quality/test implications.
• Read docs/knowledge-base/process-engineering.md for stakeholders, vision document, BPMN, use cases, and activity-diagram guidance.
• Read docs/prompt-bank/feature-spec.md when the schema work belongs inside a larger feature prompt.

Do Not

• Do not propose tables without stating the access pattern they support.
• Do not treat migrations as safe by default; call out sequencing and rollback risk.