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

portal-content

Question/alternative/feature content for the portal app, kept in its own repo so content edits don't require a Rust rebuild or touch app code at all.

Schema

Each file in questions/ is one Question (see portal's src/content.rs for the exact struct). A question has one or more alternatives; each alternative is a small form made of features, each holding zero or more requirements (input fields).

id: /some-path           # matches a route; "/" is the landing page; English slugs
name: Headline
description: >
  Markdown body text.
alternatives:
  - name: Alternative label
    description: One line explaining this path.
    action: /next-question   # id of the question to advance to on submit
    consequence: [Button label]
    features:
      - name: A feature/section heading
        description: Optional supporting text.
        requirements:
          - name: email
            label: Email
            type: email

type on a requirement is one of: text, textarea, email, tel, select. Omit for plain text. Mark a requirement optional: true if it isn't required.

There is deliberately no color/icon styling here — the app has a single brand accent variable, not per-alternative colors. And there's no branching/criteria language yet: today a human reads submissions off NATS and decides what happens next. If that grows into something an LLM posts follow-up questions into later, it publishes into the same shape these files already are — this repo's format doesn't need to change for that, just its source.

Adding a question

Drop a new questions/<id>.yaml file and reference its id from an existing alternative's action. No registration step - the app loads every file in the directory at startup.

S
Description
Question/alternative content for the portal app, kept separate so content edits never need a Rust rebuild.
Readme
228 KiB
Languages
JavaScript 100%