applied.yaml and index.yaml still described review in the passive
third person ("someone here will read this", "taken on by someone
who reads") after project.yaml and the rest of applied.yaml's own
features had already been reworked to a direct first-person "we"
voice centered on the visitor's value, not on the fact that a person
reads it.
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.