Module technical_spec 

TechnicalSpec — cahier des charges versionnable + signatures multi-parties (Story 3.8 — FR33).

A TechnicalSpec materialises a syndic-produced specification for an ACP (or a specific building inside the ACP). It is versionnable with a strict SemVer-like triple (SemVer) and signed off by one or more parties (SignatoryRole).

Workflow

1. The syndic creates a spec in TechnicalSpecStatus::Draft.
2. Once ready, the syndic submits it: the status moves to TechnicalSpecStatus::PendingSignatures (no further edits).
3. Each required_signatures slot is filled via a TechnicalSpecSignature append-only row. When all required slots are filled, the use case promotes the spec to TechnicalSpecStatus::Approved.
4. A subsequent version bumps the spec (TechnicalSpec::bump) — if the bump is major (requires_resignature is true), the new draft must collect fresh signatures from every required signatory.

Invariants enforced at new() time

• title.len() in [5, 200]
• description.len() in [50, 10_000]
• deliverables non empty, at most 50 entries, each non empty
• required_signatures non empty, at most 10
• attachments at most 20

Structs

SemVer

Strict semantic version triple (major.minor.patch).

TechnicalSpec

TechnicalSpecSignature

Enums

SignatoryRole

Role authorised to sign a TechnicalSpec. Mandataire roles (AMO, Lawyer, Architect) must additionally carry an active crate::domain::entities::Mandate covering the spec’s ACP — the use case enforces this guard.

TechnicalSpecStatus

Constants

MAX_ATTACHMENTS

MAX_DELIVERABLES

MAX_DESCRIPTION_LEN

MAX_REQUIRED_SIGNATURES

MAX_TITLE_LEN

MIN_DESCRIPTION_LEN

MIN_TITLE_LEN