docs: update CHANGELOG + tasks for the backend skeleton sprint 0
- CHANGELOG.md: detail every B0.1..B0.8 deliverable + spec deltas D-008 (ttp_version coexists), D-009 (audit hash chain v1), D-010 (no type_annotation_map on declarative base). - tasks/todo.md: tick every B0.x item. - tasks/spec-decisions.md: log D-008, D-009, D-010 alongside the pre-existing D-001..D-007.
This commit is contained in:
@@ -56,3 +56,30 @@ Never re-displayable.
|
||||
**Decision.** Reverse proxy (Caddy + TLS + IP allowlist) handled by existing RT
|
||||
infrastructure. Mimic ships an HTTP listener on localhost only; the deployment
|
||||
playbook wires it behind the existing proxy.
|
||||
|
||||
### D-008 — `ttp_version` table (overrides spec H32)
|
||||
**Context.** Spec H32 reads "snapshot of replayability = `run.snapshot_json` only
|
||||
(no separate `ttp_version` table)". The kickoff backlog (B0.2, team-lead
|
||||
directive) explicitly re-introduces the table.
|
||||
**Decision.** Both coexist:
|
||||
- `ttp_version` (immutable, hash-stamped) tracks every publication / edit of a
|
||||
TTP. Used by importers, audit log, and TTP diffs.
|
||||
- `run.snapshot_json` remains the source of truth for replay independence (each
|
||||
run carries a self-contained snapshot of the resolved TTPs).
|
||||
Net cost: one extra table for clear semantics — TTP lineage and run replay
|
||||
solve different problems.
|
||||
|
||||
### D-009 — Hash-chain in `audit_log` from v1
|
||||
**Context.** Spec H30 places the hash chain in v2; F13 / R-O5 only mandate the
|
||||
write-only role for v1.
|
||||
**Decision.** `prev_hash` / `row_hash` columns ship from day one and are
|
||||
populated at insert time (SHA-256 of canonical record + previous hash). The
|
||||
chain *verifier* lands in v2. Cost is negligible (one SELECT + one SHA-256 per
|
||||
audit insert) and avoids a destructive migration later.
|
||||
|
||||
### D-010 — Type-hinting strategy for the ORM
|
||||
**Context.** Flask-SQLAlchemy 3 rejects per-base `type_annotation_map`.
|
||||
**Decision.** UUID primary keys use the explicit `PG_UUID(as_uuid=True)` type
|
||||
on `UuidPkMixin`. Foreign-key UUID columns rely on SQLAlchemy 2's built-in
|
||||
`Uuid` mapping via `Mapped[uuid.UUID]`. No `type_annotation_map` on the
|
||||
declarative base.
|
||||
|
||||
Reference in New Issue
Block a user