Files
questions/aggregates.yaml
T
Bendik Aagaard LynghaugandClaude Sonnet 5 c07f8c880d
Lint and reload / lint (push) Successful in 2s
Lint and reload / reload (push) Successful in 0s
Drop the investor concern entirely
It was a worked example of the empathic pattern, not a feature: every
alternative should be empathic, informative, and helpful - information
that gives an answer, not necessarily a path to choose. The pattern
stays (voice rules, README); the investor pages, aggregate, review
alternative, and front-page gateway go. The investors KV bucket and
its test records linger in NATS unreferenced - purge at leisure.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-12 23:33:53 +02:00

69 lines
2.3 KiB
YAML

# The full state graph for every bucket that wants event-sourced,
# CAS-protected transitions - see portal's src/aggregates/mod.rs. A
# bucket with no entry here still works (plain KV mutate-in-place, no
# event log). `bucket` doubles as both the KV bucket name and the
# JetStream event-subject segment (events.<bucket>.<id>) - one name,
# not two.
#
# Pages (review.yaml, subscribed.yaml, index.yaml) reference these
# bucket names and `to:` state names by string; they never re-declare
# the graph itself. Add a new aggregate here alone - no portal code
# change needed.
aggregates:
# One continuous graph per person, applicant through employee - the
# bucket name stays "applicants" even as a record progresses past the
# applying stage (a deliberate trade: one chain of events per person,
# no identity-linking between separate buckets).
- bucket: applicants
initial: open
states:
open: { event: applied }
invited: { event: invited }
declined: { event: declined }
active: { event: onboarded }
departed: { event: departed }
transitions:
open: [invited, declined]
invited: [active, declined]
active: [departed]
- bucket: subscribers
initial: open
states:
open: { event: subscribed }
unsubscribed: { event: unsubscribed }
transitions:
open: [unsubscribed]
- bucket: projects
initial: open
states:
open: { event: submitted }
accepted: { event: accepted }
declined: { event: declined }
transitions:
open: [accepted, declined]
- bucket: organizations
initial: prospect
states:
prospect: { event: identified }
client: { event: became_client }
past_client: { event: churned }
transitions:
prospect: [client, past_client]
client: [past_client]
# Proposals to change this very repo - the question architecture
# dogfooding its own development. Approval hands off to an n8n
# automation that opens a PR against this repo (see the infrastructure
# repo's development-commit workflow); the lint CI gates the merge.
- bucket: development_proposals
initial: open
states:
open: { event: proposed }
approved: { event: approved }
rejected: { event: rejected }
transitions:
open: [approved, rejected]