50 lines
1.8 KiB
Markdown
50 lines
1.8 KiB
Markdown
# portal-content
|
|
|
|
Question/alternative/feature content for the [`portal`](../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).
|
|
|
|
```yaml
|
|
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.
|