Files
questions/aggregates.yaml
T
Bendik Aagaard LynghaugandClaude Sonnet 5 8d10e99726
Lint and reload / lint-and-reload (push) Successful in 2s
Actor state machines: employee lifecycle, investors, organizations wired, development proposals
- applicants grows past the one decision: invited -> active (onboarded)
  -> departed, one continuous graph per person.
- investors: open -> in_dialogue -> committed -> divested, with decline
  edges; submission via a new "I want to invest" alternative on /.
- organizations (prospect -> client -> past_client) finally gets pages:
  a review listing with its transitions and a record-a-prospect form.
- development_proposals: the question architecture dogfooding its own
  development - /develop-proposal takes proposals from anyone (human
  today, an LLM later through the same public form), /develop lets an
  owner approve or reject, and approval hands off to the automation
  that opens the PR (see infrastructure's development-commit workflow).
  The repo's own lint CI gates the merge, same as any human commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-12 22:04:11 +02:00

82 lines
2.6 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]
- bucket: investors
initial: open
states:
open: { event: expressed_interest }
in_dialogue: { event: entered_dialogue }
committed: { event: committed }
declined: { event: declined }
divested: { event: divested }
transitions:
open: [in_dialogue, declined]
in_dialogue: [committed, declined]
committed: [divested]
# 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]