One binary: the lint and the trainer are commands of portal

portal serve runs a site; portal lint is what iris was; portal plan,
build, report and the rest are what portal-trainer was. One source at
one version, so the three never disagree about what content means.
Both histories are merged in (subtree). The release attaches the bare
binary for a content repo's CI. The trainer's plans, intakes, engines
and reference prompt come along; its runs stay in the old repo.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt

portal-portal/aggregates.yaml

@@ -0,0 +1,17 @@
+# One onboarding per business. `open` is the intake as submitted; the
+# generator (portal-trainer generate) turns it into a draft content
+# repo; the business reviews the draft and either it goes live or it
+# comes back for another pass.
+aggregates:
+  - bucket: onboardings
+    initial: open
+    states:
+      open: { event: intake_received }
+      drafted: { event: draft_generated }
+      revising: { event: revision_requested }
+      live: { event: went_live }
+      declined: { event: declined }
+    transitions:
+      open: [drafted, declined]
+      drafted: [live, revising, declined]
+      revising: [drafted, declined]

portal-portal/needs.yaml

@@ -0,0 +1,41 @@
+# The onboarding site is a portal site, so it is held to a needs spec
+# like any other.
+needs:
+  - id: onboard-business
+    who: someone who runs a business where requests, approvals and handovers get lost
+    wants: a working site for their own roles, without commissioning software
+    via: Describe your business and get a first draft
+    lands_in: onboardings
+    handled_by: owners
+    done_when: [live, declined]
+    max_steps: 1
+    # The intake is the interview: two to reach them, four about the work.
+    max_fields: 6
+
+personas:
+  - id: contractor-owner
+    need: onboard-business
+    text: >
+      I run a building firm. Enquiries come by phone, text and email
+      and we lose track of who promised what. I want one place where
+      they land and my project managers pick them up.
+
+  - id: clinic-manager
+    need: onboard-business
+    text: >
+      We are a physiotherapy clinic with six therapists. Referrals,
+      cancellations and insurance approvals all go through one inbox
+      that only our receptionist understands. I'd like that sorted.
+
+  - id: sports-club
+    need: onboard-business
+    text: >
+      I volunteer for a youth football club. Parents sign kids up,
+      coaches need to approve them, and the treasurer chases fees.
+      Right now it's a spreadsheet and a group chat.
+
+  - id: sceptical-founder
+    need: onboard-business
+    text: >
+      I've been burned by agencies before. If I can explain my
+      workflow and see something real before paying anyone, I'm in.

portal-portal/questions/desk/_section.yaml

@@ -0,0 +1 @@
+qualifies: owners

portal-portal/questions/desk/index.yaml

@@ -0,0 +1,25 @@
+name: Which businesses are waiting on us?
+responsible:
+  name: Bendik Aagaard Lynghaug
+  contact: bl@uhhm.no
+alternatives:
+  - name: Onboardings
+    description: >
+      Run `portal-trainer generate` on an open intake, push the draft,
+      send the link, then mark it drafted. Revisions come back here.
+    action: /desk
+    consequence: [Confirm]
+    features:
+      - name: ""
+        description: ""
+        resource:
+          source: { kind: kv, bucket: onboardings }
+          requires_group: owners
+          transitions:
+            - { to: drafted, label: Draft sent }
+            - { to: declined, label: Decline }
+            - { from: drafted, to: live, label: Went live }
+            - { from: drafted, to: revising, label: Revision asked }
+            - { from: drafted, to: declined, label: Decline }
+            - { from: revising, to: drafted, label: Revised draft sent }
+            - { from: revising, to: declined, label: Decline }

portal-portal/questions/how.yaml

@@ -0,0 +1,21 @@
+name: How does an answer become a finished job?
+description: >
+  Every page asks one question. Every answer lands with the person
+  whose job it is, and carries its own next steps.
+alternatives:
+  - name: A visitor answers
+    description: >
+      They pick what they came for and fill in the few fields that
+      person needs. They are told who reads it and when.
+  - name: The right role sees it
+    description: >
+      Each role has a desk listing what is theirs, with one button per
+      step your process allows - quoted, approved, closed.
+  - name: Nothing waits unseen
+    description: >
+      Every case has a state and an owner, so what is open, and with
+      whom, is always one page away.
+  - name: Describe your business and get a first draft
+    description: Five answers in your own words.
+    action: /
+    consequence: [Start]

portal-portal/questions/index.yaml

@@ -0,0 +1,49 @@
+name: What does your business keep doing by hand?
+description: >
+  Tell us who comes to you, what you keep track of, and who handles
+  what. You get a site that asks each of those people the right
+  question and moves every answer to the person who acts on it.
+responsible:
+  name: Bendik Aagaard Lynghaug
+  contact: bl@uhhm.no
+alternatives:
+  - name: Describe your business and get a first draft
+    description: >
+      Five answers in your own words. We turn them into pages, forms
+      and a desk for each role, and send you a link to try it.
+    action: /received
+    consequence: [Send it]
+    record_as: onboardings
+    encouragements:
+      - Write it the way you would explain it to a new colleague.
+    features:
+      - name: You
+        requirements:
+          - { name: business, label: Business name }
+          - { name: email, label: Your email, type: email }
+      - name: The work
+        description: Plain words are best. Stages, handovers and waiting are what we listen for.
+        requirements:
+          - name: what_we_do
+            label: What you do
+            type: textarea
+          - name: who_comes_to_us
+            label: Who comes to you, and what each of them wants
+            type: textarea
+          - name: what_we_keep_track_of
+            label: What you keep track of, and the stages it goes through
+            type: textarea
+          - name: who_is_involved
+            label: Who on your side handles what
+            type: textarea
+          - name: what_slows_us_down
+            label: Where things get lost or wait today
+            type: textarea
+            optional: true
+
+  - name: See how a question becomes a finished job
+    description: >
+      One enquiry followed from the visitor's answer to the desk that
+      closes it.
+    action: /how
+    consequence: [Show me]

portal-portal/questions/received.yaml

@@ -0,0 +1,15 @@
+followup: true
+name: What happens with what you sent?
+description: >
+  Bendik reads every intake. Within two working days you get a link to
+  a working draft built from your answers.
+alternatives:
+  - name: You try the draft as each of your roles
+    description: >
+      Click through it as a customer, then as the colleague who handles
+      that customer. Tell us what reads wrong and the draft comes back
+      revised.
+  - name: Back to the start
+    description: ""
+    action: /
+    consequence: [Back]

portal-portal/site.yaml

@@ -0,0 +1,2 @@
+title: Portal
+lang: en