task-e

docs/adr/0007-quotation-revision-strategy.md

@@ -0,0 +1,18 @@
+Status:
+accepted
+
+Context:
+Quotation revision was introduced in Task E, but the rules before approval workflow were still ambiguous.
+Task E.1 needs a stable rule so Task F can build approval on top without changing quotation lineage again.
+
+Decision:
+- Revision is allowed only when the current quotation status is `approved`, `sent`, `accepted`, or `rejected`.
+- Revision is not allowed for `draft` or `cancelled`.
+- A new revision keeps the same quotation family using `parentQuotationId`.
+- A new revision copies header, items, customers, and topics only.
+- A new revision is created with the `revised` status when that master option exists.
+
+Consequences:
+- Sales can revise commercially meaningful documents without reopening early drafts.
+- Approval work can later key off a stable quotation family and revision chain.
+- Follow-ups and attachments are still out of the revision snapshot and remain technical debt until explicitly designed.

docs/adr/0008-attachment-storage-strategy.md

@@ -0,0 +1,15 @@
+Status:
+accepted
+
+Context:
+Task E introduced quotation attachments as metadata only.
+Task E.1 confirms that approval should not start on top of an unstable file-storage design.
+
+Decision:
+- Keep quotation attachments metadata-only for now.
+- Store file identity, original name, path, type, size, uploader, and timestamps in CRM tables.
+- Do not build upload transport, storage provider logic, signed download URLs, or binary retention policy in Task E or E.1.
+
+Consequences:
+- Task F can reference attachment metadata without being blocked by storage implementation details.
+- A later storage task must define provider abstraction, permission checks, retention rules, and migration strategy for existing metadata rows.