4 Commits

Include renames

Author	SHA1	Message	Date
Bendik Aagaard LynghaugandClaude Sonnet 5	20b24f08c2	Reseed lost event history from the KV projection on transition ... A record whose event log is empty (the EVENTS stream was purged, or the record predates event-sourcing) but whose projection exists used to be stranded - replay found nothing, every transition failed with "unknown item". transition_or_reseed reconstructs a minimal one-event history from the projection's own current state and retries, making "zap the whole event stream" a recoverable operation by design instead of a slow-motion data loss. Reseed races are guarded by the same expected-sequence-0 CAS create uses. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-12 22:27:57 +02:00
Bendik Aagaard LynghaugandClaude Sonnet 5	84c3fad339	Make aggregate state graphs content-driven, not compiled Rust ... Six hand-maintained copies of the bucket->aggregate-type table (4 per-type State enums, content::aggregate_type_for_bucket + is_valid_transition_target, answers.rs's two dispatch matches, backfill_events.rs's own migration table) collapse into one: questions/aggregates.yaml, loaded and hot-swapped in AppState.aggregates the same way AppState.questions already is. aggregates/mod.rs's replay/create/transition now run off a runtime-loaded AggregateSchema instead of a compile-time AggregateKind trait impl per type - the CAS/JetStream mechanics underneath are unchanged. A new aggregate type is now a content-only change, no portal deploy required. backfill_events.rs is deleted outright rather than ported - its migration job was already done and production data here is minimal and expendable (the EVENTS stream gets purged by hand post-deploy). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-11 21:43:32 +02:00
Bendik Aagaard LynghaugandClaude Sonnet 5	aa18c69be4	Add Organization aggregate (client-as-status), wired but inert ... Prospect -> Client -> PastClient (Prospect -> PastClient allowed directly too - a prospect that never converted). "Client" is a status on Organization, not a separate aggregate, per the event-sourcing plan's design decision. Wired into the same dispatch points as the other three aggregates (content.rs's bucket map, answers.rs's create/transition dispatch) so it's ready the moment content references an "organizations" bucket - nothing does yet, so this lands compiled and tested but with zero production surface. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-06 12:01:17 +02:00
Bendik Aagaard LynghaugandClaude Sonnet 5	ebf4bf91b3	Event-sourced applicant/subscriber/project aggregates, generalized resources ... Replaces the free-string, direct-KV-mutate state model in answers.rs with a proper event log (events/store.rs, JetStream-backed, CAS via expected_last_subject_sequence) and three pure state machines (aggregates/{applicant,subscriber,project}.rs). Closes a real lost-update race in the old transition_answer (concurrent decisions on the same item could both win, publishing contradictory events). KV buckets become best-effort read-model projections, not the source of truth. Content-declared transition targets are now validated at load/reload time against the real compiled transition tables, not accepted as arbitrary strings. Buckets renamed to describe their content, not their relation to the app (portal_applicants -> applicants, etc); "inquiry" folded into a richer "project" concept. ResourceSpec generalized beyond a single KV bucket: Kv | GiteaStarred | GiteaOrgRepos | Url sources, with an optional jq filter (via the jaq crate) to shape live data for the frontend. Url source is SSRF-guarded (https-only, rejects loopback/private/link-local, real DNS resolve). New headless question_lint binary (validates content against compiled transition tables with no NATS/OIDC/server involved) and a one-time backfill_events binary (dry-run by default) for migrating existing KV data onto the new event log. Questions get an optional `responsible` contact plus a lightweight "report this question" action. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-06 08:52:29 +02:00