RFC: preliminary design for Phase C/D without implementation in 0.2.0

[klssxx]

Context

THEKEY 0.2.0 is intentionally small. Future work (Phase C: stronger identities, evidence signing, concurrency, exceptions, RFC policy; Phase D: OSS attractiveness) is planned but must not ship in 0.2.0.

Requisito o riesgo al que responde

• Requisito: THEKEY_CONTRACT §3 (Evidence is hash-sealed) — Phase C evidence signing extends, not replaces, the chain.
• Riesgo cubierto: THREAT-T2 (Falsificación de evidencia) — signing is the future mitigation that makes the chain cryptographically binding, not merely hash-chained.

Impacto si no se resuelve

Without a recorded design, Phase C work may be sketched ad hoc in PRs, risking scope creep into 0.2.x or an inconsistent signing model later.

Acceptance criteria

• A preliminary design doc under governance/phase-c/ covering: identity model, evidence signing, concurrency model, exception handling, RFC policy lifecycle.
• Explicitly marks what is NOT in 0.2.0 and what gates a Phase C merge.
• Links to the relevant THREAT_MODEL sections (T2, T3, T4) it addresses.

Cómo se verifica

# design review only — no code gate
python -m thekey demo
# expected: still RELEASE_ELIGIBLE, gates_passed: 4/4 (no behavioral change)

Evidencia en event store

This is a design RFC; on merge record Closes #8 + the design doc pointer in the PR body. No event-store mutation is expected (docs only); the demo must remain RELEASE_ELIGIBLE with evidence_mismatches: [].

Docs afectados

• README / README.en actualizado (roadmap pointer)
• CHANGELOG entrada añadida
• DECISIONS.md si hay decisión de diseño